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(57) The invention concerns methods for bridging a 
HAVi sub-network and a UPnP sub-network. 

For making UPnP devices available to the HAVi 
sub-network, the following steps are implemented: 

discovering UPnP devices and/or services on the 
UPnP sub-network and corresponding to a selec- 
tion criterion; 

declaration, by a sub-network bridging device, of 
each discovered UPnP device as a HAVi DCM and 
of each discovered UPnP service as a HAVt FCM 
on the HAVi sub-network. ' " v.. 



For making HAVi devices available to the UPnP 
sub-network, the following steps are implemented: 

discovering HAVi software elements of the HAVi 
sub-network corresponding to a selection criterion; 
representing, in a sub-network bridging device, 
each of said discovered elements by a UPnP proxy 
service identified by a port number attributed by 
said sub-network bridging device; and 
announcing each said proxy services on the UPnP 
sub-network. 

The invention also concerns a device for imple- 
menting the above steps. 
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Description ; 

[0001] The invention concerns ; methods to- bridge 
HAVi and UPnP sub-networks, a first method address- 
ing the issue of making UPnP objects available to HAVi 

•objects^ issue ot mak " 

ing HAVi objects aval labia to UPnP objects. The mven- 
tion also concerns a bridge device. 
10002] The invention applies among others to home 
; networks. v " 

f0603] : Several sub-networks based on different phys- 
ical media (wired and wireless) and applications are ex^ 
pected to coexist in a digital home network. Common 
examples of wired physical media include the coaxial 
cable twisted pair wiring, power line and optical fibers. 
A digital home network also needs to contend with the 
technological developments within the computer, con- 
sumer electronics/telephony and home automation in- 

: dustries. .... 
[0004] There have been two recent initiatives within 
the industry to address different needs: 

1. Home Audio-video interactivity (HAVi) ■■ 

2. Universal Plug and Play (UPnP); 

rbOdS] There is a need for harmonization of the two 
system approaches in order to ensure coexistence and 
interoperability of devices within these domains. One of 
the goals of the invention is to accomplish the bridging 
• of the tvk>'ts6hna6^Vrip>«iiabhe^. * 
[0006] The first initiative, Home Audio-Video Interop- 
erability (HAVi), started within the consumer industry is 
ah attempt to accomplish high speed interconnectivrty 
over an IEEE 1394 serial bus network for transacting 
audio/visual data. This initiative was specifically intend- 
ed to address the needs of the consumer electronics de- 
vices to enable interactivity (with user involvement in a 
user-device interaction paradigm) and interoperability 
(with no user involvement in a device-device interaction 
paradigm). Further, within HAVi, there is a strong em- 
phasis on enabling streaming applications in addition to 
control applications. An example of a streaming appli- 
cation would be an application transferring a video 
stream from a recording device to a decoder or display, 
while an : example of a control application would be an 
application' for programming the behavior of devices. 
This implies a support for both isochronous and asyn- 
chronous transactions. 

[0007] The other key features of HAVi include: 



-1. Hot Plug and Play 

2. Hardware and Operating System Platform neu- 
trality 

3 Support for legacy devices (i.e. devices with no 
HAVi functionality) and a gradual evolution to sup- 
port new technologies 



Play (UPnP), While HAVi is intended primarily for a high 
speed IEEE 1394 network for AudioNideo transactions. 
UPnP'is an initiative that is physical layer agnostic and 
expects to work on a TCP/IP network. The general no- 
5 tions and paradigms are based on . thalnternet protocols 
with additions to support the notions of. plug and play, 
r0009] The following non-exhaustive, list of docu- 
ments describe the above architectures in their current 
state of development, at the priority date of ttie present 
10 application: 

For HAVi: . . 

The HAVi 1 .0 beta+ specification-dated October a, 

1998 - 
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[0008] The second initiative is Universal Plug and 



[0010] ; The UPnP technology comprises, a set of pro- 
tocols based on TCP/IP: 

. -Automatically choosing an IP Address in an Ad-Hoc 
1 :|Pv4 Network' (<draft-ietf-dhc-ipv4-autoconfig- 
. ■ 04.txt>) 

- 'Simple Service Discovery Protocol 1.0' («httD_7/ 
' . search, ie. orq/internet-dra fts/draft-cai-ssd : p- 

v1 -01 txt >) "' 
•Multicast Discovery of DNS (Domain Name Server) 
Services' (<draft-manning-multicast-dns-01 txt>). 
: • -Extended Markup. Language' - XML (1,0 W3C rec- 
commendation) s : - ' 

30 [0011] More information concerning these two archi- 
tectures is available on the corresponding websites, ie. 
www HAVi.org and www UPnP.org. 
[0012] The fundamental goal of the interoperability is 
to ensure that a uniform control paradigm, i.e. model, is 

35 presented so that devices in both the H AV. sub-network 
and the UPnP sub-network are able to interact with de- 
vices and perform control functions over themrespectwe 
sub-network boundary. 

[0013] Since HAVi and UPnP based devices are ex- 
40 pected to proliferate within the home, it would be nec- 
essary to ensure the interoperability of devices within 
these domains. Figure 1 represents an example of a 
■ home network composed of a HAV. based home sub- 
• network and a UPnP based home sub-network that are 
45 bridged together Nodes A and D are displays where the 
user can view the network topology and can control, 
through an appropriate user interface, any node on ei- 
ther network. This implies that from node A, the user 
should for example be able to detect the connection of 
so node E to the UPnP network and should be able tocon- 
trol it In a similar manner, a user of node D on the UPnP 
sub-network should be able to detect the appearance of 
a new HAVi device within the HAV. sub-network and 
should be able to control it. • 
55 [0014] In Figure 1, the two sub-networks are built over 

two different media. However, the problem to be solved 
is the same in the situation where both network archi- 
tectures are built over the same media as shown in Fig- 
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ure 2: The nodes A/B and C are HAVi aware and the 
nodes- C, D and E are UPnP aware. In both configura^ 
tions, there is amode (node C in both examples) which 
implements* the -bridge function in order to enable the 
control of any across the:,entire network. - 
[0015] Theihventibn.aims at providing an interfacing 
solution in both of -the above cases. 
[0016] : The object of the invention is a method for 
bridging a HAVi sub-network and a UPnP sub-network 
comprising the steps of: 

discovering UPnP devices and/or services on the 
. , UPnP sub-network and. corresponding to a selec- 
tion criterion; 

declaration, by a sub-network bridging device, of 
each discovered UPnP device as a HAVi DCMand 
of each discovered UPnP service as a. HAVi; F CM 
on the HAVi sub-network. 

[0017] According to a preferred embodiment the dis- 
covery step is carried out using Simple Service Discov- 
ery Protocol (SS DP) functions.. 

[001 8] Another object of the invention is a method for 
bridging a HAVi sub-network and a UPnR sub -net work 
comprising tho. stops of: K ' * \. -. . : ,z 

- . discovering, HAVi .software -elements* of the 1 HAVi 
sub-network corresponding to a selectipn:,criterion; 
representing, in a sub-network bridging device, 
each of said discovered elements by a UPnP proxy 
service -identified by a port number attributed by 
said sub-network bridging device; and 
announcing each said proxy services on the UPnP 
sub-network. * 

[001 9] According to a preferred embodiment, the dis- 
covery step comprises the step of requesting, by said 
sub-network bridging device, a list of software elements 
from a HAVi registry. 

[0020] . According to a preferred embodiment of the in- 
r vent ions above, the selection criteriorvis HTTP/HTML 
, capability. . . - . -.i - - 

[0021] Another objectof the invention is ,a device *fpr 
bridging a UPnP sub-network and a HAVi sub-network 
implementing the above method steps. 
[0022]. Other characteristics and advantages of the in- 
vention will become apparent through the description of 
a non-limiting : preferred embodiment, described with 
the help of the attached drawings among which: 

figure 1, already described, represents a HAVi net- 
work and a UPnP network linked through a bridge 
device; 

figure 2, already described, represents a single net- 
work comprising both HAVi and UPn P compliant de- 
vices; 

figure 3 represents the networks of figure 1 in which 
each network comprises an HTML browser capable 



device; .*-.,■ 
figure 4 is a schematic diagram of protocol stacks 
• .-in. the bridge device. : , 

s [0023] In addition to the documents- cited in^the intro- 
duction of the present application.one.should also refer 
to the Hypertext Transfer Protocol .('HTTP'):,"! .1 for fur- 
ther background information.. • ~ (I , . 
[0024] Within the context, of the UPnP network, -it is 

10 necessary to detect the entry of a new device into the 
network, announce its capabilities in a well defined man- 
ner and allow the commencement of interaction with 
other devices within the network. The SSDP protocol 
and XML operating over the TCP/IP network are used 

is to accomplish this functionality. , ■ 

[0025]- For user control, HTML may be used instead 
of XML 

[0026] As described earlier, ; HAVi is a complete sys- 
tem solution to the interoperability of devices with a 
20 IEEE 1394 interface;. HAVi addresses, among others, 
the following issues: - , - , 

1 . Registration of devices/functions 

2. Communication media management (the media 
2s being an IEEE 1394 serial bus in this case) 

3. ; Modeling devices and functions within devices 
1 ; * using device control modules ('DCMs') and function 
- . control modules ('FC Ms'): ; . Vi - 

30 - the list of services provided .by.. the DCM in- 

cludes. connection .management, status que- 
ries for the device and its plugs 
- there is .a comprehensive list of FCMs repre- 
senting the most common consumer electronic 

os functional elements 

4. Event management (using an event manager) 

. 5. Stream management (using a stream manager) 
6. Resource management r 
40 , 7. Support for legacy devices 

■ t . .-8. Data Driven Interaction- (DDI) mechanism t 

. [0027] Some of-the services^offered within the HAVi 
paradigm are-similar -to those envisioned within,the UP- 

45 n P paradigm. The important additions to HAVi include 
specific provisions for stream management, communi- 
cation media management and resource management. 
These additions are quite important in the context of an 
A/V network based on the IEEE 1 394 bus, which impos- 

so es severe real time constraints. 

[0028] One of the issues regarding the interaction be- 
tween the HAVi and UPnP sub-networks is the need for 
a common user control protocol. The DDI mechanism, 
which is standard in HAVI, is not standard within the UP- 

ss n P network. HTML is standard in an IP based computer 
network (including UPnP), but is not included in HAVI. 
In order to solve this problem, the following functionali- 
ties are required: ■ t ■ ■ 
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. a user control protocol which can be used across 

the whole network HTML 
. A bridge function which will allow : = - 

. ■ ;-:V(a) connection^:the.twod discovery 

' ' ^ca^m^ HTML data overthe entire net- 

• ... . ' work •■■ -■■ • - ■ • 

r00291 The Hypertext Transfer Protocol (or HTTP) is 
SesVrespo' se protocol This protocol ,s .ntrcduced 
fn the current context since it is the proposed mecha- 
nism to accompiish the bridging functiona.luded to m 

Sserver mooel tor devices using HTTP. Two objects 
arfe involved in HTTP : the client, which sends a com- 
an origin server that receives the command 

Sds (or commands) which inc.ude the 1oi.ow.ng 



function is .to connect both discovery, methods. For that 

we need: - ; ' " ' * ;"" t . 

-" a W lowest** *'<^*^^ 
' LXice for a HAV. application within the brdge de- 

. awaytorepresentandtoreachaHAVidevice/se^- 
: fcX a UPnP application within the bridge dev.ce. 
rooaei The UPnP protocol for this function isjhe Sim- 

HS"pTcmes two protocols which are difleren. trom 
HTML. To solve the problem we need. 
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1. Option 

2. Get 

3. Head 

4. Post- 

5. Put 

6. Delete 
7 . Trace 
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ro032I The most commonly used command is GET < 
URL> where the Uniform Resource Locator (URL) 
oSs towads the object to be obtained. This Terence 
?s composed of two parts the first points towards the 
se^erequipmentand the second pointstowardstheob- 

fecTassociated with the command. Th.s target object 
can be an existing object such as a HTML scnpt or a brt- 

point towards something that has a me ™9 
WEB server but does not represent any real ob,ect „ Th» 
^sed, for instance, in an HTML script to s.gna I tc he 
WEBserverthattheuseriustselectedan^on.Afterthe 

"ser selects the ^^^^J^S^Z 
icon 'With a URL which- will 1 be: sent to the WEB server 
«h3h the GET command).A URL reference can ,n- 
Sude some parameters as a command from upper .ayer 

STBasically, a user (application) needs is to be 
Se to detect the network changes (new or removed 
delVe/services) and then has to be able to control de- 
v'estrough a User interface (a well known language 

™ P 3 Twe first address the user control interface 
£ode of both networks. Then, we apply the recom- 
mended solution to bridge other control pro oco. to op 
erate UPnP and HAV. services over the ent.re network^ 
rM3Sl Each network technology specifies a way to 
dynamically discover the appearance or the disappear- 



, 20 - a user control protocol which can be used across 
. .; . the whole network . HTML/HTTP, 
. a way to implement the HTTP protocol wrthm the 
, HAVi paradigm . ' 

[0038] : Regarding the bridge of other services (UPnP 
or HAVi) we heed: .o;/H->'- 

/'ia way, for a HAVi applications to operate the UPnP 

,: service/device; „, '.ho u AVi 

. a way, for a UPnP application to operate, the HAV. 

service/device. 

1-00391 In Figure 3, the bridge function is included in 
Kvice C Any device, irrespective of itsfunct.onalrty, 
SJ^Sb^tUnc.icn.V^n^thal 
Z host device gathers the HAVi m.ddleware andjhe 
UPnP protocol stack. For clarity purposes, the C dev ce 
aTcordi™ t° the present embodiment does not provrte 
Ty fSnality other than the bridge as descnbed be- 

'rOMOV The next section describes all operations nec- 
essary to realize the following scenarios: ■ ■ 
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■ Scenario 1: the network topology is the same as 
<. Sown in the Figure 3 except that the , E dev.ce,s 
not present. The User applicafon of A the ™ 
browser) after power on, is able to give back to the 

. (discovery through the HAVi reg.stry). The E dev.ce 
so is plugged on to the UPnP network. The User ap 
plicatS. detects this new device (through the AN- 
NOUNCE method of SSDP). Then the user w... be 
able to control the E device using HTML. 

ss Scenario 2: the network topology is the same as 
shTn in the 3 except that the B dev.ce ,s not 
present. The User applicat.on of D (the HTML 
browser) after power on, is able to g.ve back to the 
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user the network list of the HTML controlled devices 
(discovery; by SSDP queries). TheB device is 
plugged on to the HAVi network. The User applica- 
tion detects this new device (announcement). Then 
the user will be^able to= control the B device using 
> HTML -<•<•"•'• ^ o - 

[0041] HTML data is transported using the HTTP pro- 
tocol. However, HTTP is a means to transport any type 
of hyper text based content. Just as through HTTP we 
are able to obtain any User Interface object, such as an 
icon or a bitmap, we are able to transport XML content 
as well. Today, 1 the most popular Markup language is 
HTML. Consequently many product tools already exist. 
This is the reason we recommend using it within the 
HAVi network. XML is an emerging standard, and could 
be used instead of HTML without any modification to bur 
proposal since XML content can be transported over 
HTTP as well. According to a variant embodiment, XML 
: and HTML are used jointly. 

[0042] This section proposes to add HTTP (HTML) 
capabilities to the HAVi specification.. This protocol is a 
simple command/response protocol between a control- 
ler and a target (called HTTP server as well). In HAVi, 
each device is represented -by a ^software component 
called a DCM (Device Control Module).:This DCM con- 
tains a certain number of well specified entry points (as 
a set of functions) which can be used (called) by any 
other software element of the HAVi network. .Like a C 
function, when a software element calls a function of a 
DCM (whether remotely or locally, it is transparent for 
the caller), an associated process is started and the 
function returns the result of the process. To implement 
the HTTP paradigm, this invention proposes to add a 
new function set () within the DCM API to offer the pos- 
sibility to handle the HTTP protocol between two HAVi 
software elements - for example between an application 
(a browser) and a DCM (the HTTP server)-. HAVi uses 
the IDL (Interface Definition Language) to specify a 
function. Due the nature of the HTTP protocol, it is pos- 
sible that HTTP requests or responses contain a very 
large payload. The transport layer of. HAVi specifies a 
limit on the message size that can be exchanged be- 
tween two HAVi software elements. However, HAVi 
specifies a way to handle such large messages by a rec- 
ommended design of the API of the element potentially 
involved in such communications (see APIs for Bulk 
transfer). 

[0043] The following code illustrates the proposed 
API extension for the DCM which would implement an 
HTTP server. 

enum FileLoc {START, MIDDLE, END}; 
[0044] Permits to indicate whether the message from 
a producer to a consumer is the first one, a middle one 
the last one. It the stream to be sent .fits into one mes- 
sage, the END value will be used. 
Status DCM::HttpOpen( 

in short clientBufferSize, 
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. . in Ope ration Code opcode, \ -< 

out long cid, /. - . v- ;i ... 

out short ServerBufferSize) t , v 

clientBufferSize : indicates the maximum size (in 
5 bytes) of a message accepted by the^requ ester. The 
DCM will take into account of that parameter .during the 
sending of the HTTP response to the client. • 

opCode : this is the operation code the DCM will 
use to give back to the client the HTTP response. The 
io client function identified by this operation code must be 
designed according to the prototype named <client>:: 
HttpResponse. 1 . . 

- . cid : the identifier of this HTTP connection with the 
DCM. It allows several connections from the same soft- 
15 ware element client and also permits to match a re- 
sponse with a request. > 

ServerBufferSize : ; indicates the maximum size (in 
bytes) of a message accepted by the DCM.. The HTTP 
client will take into account of that parameter during the 
20 sending of the HTTP requests..,. 

[0045] ' This function allows a software element client 
(or HTTP client) to open a HTTP connection with a DCM. 
[0046] The error codes for this function are the follow- 
ings: 

25 DCM::ENUM_CONN: maximum number of 

opened connections is reached for this DCM 
DCM: :E ALLOC: resource allocation error 
Status DCM:: HttpClose(in long cid) ; . , 
[0047] The parameter cid is the identifier of this HTTP 
30 connection with the DCM. This function is used to close 
; a connection with a Web proxy; FCM. The error : code is 
the following: u . 

DCM::ECID: The cid is unknown. - • . 
. - Status DCM::HttpRequest( 
35 : in long cid,. 

in FileLoc where, 
in sequence<octet> data) 
Parameters = 

cid: the identifier of the connection between the 
40 HTTP client and the DCM (acting as a HTTP server) ob- 
tains by the HTTP, clientf rom a DCM::tfttpOpen call. 
- where: informs the: DCM that this message is the 
v first, the. last or a middle one.of the request 

data: contains-a part or. the.entire request accord- 
45 ing to the HTTP protocol.. 
... Description 
This function allows a software element client (or 
HTTP client) to send a request to a DCM acting as a 
HTTP sever according to HTTP 
50 Error codes 

DCM: ESIZE: the data exceeds the size of the buff- 
er in the receiver. The receiver has not received or proc- 
essed the data. It is left to the implementation how the 
sender reacts to this status error. 
55 DCM::EFAILED: the receiver has aborted the 

transfer of the current sequence of data transfers. The 
sender shall abort the transfer of the current sequence. 
DCM::ECID: The cid is unknown. 
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Status <Client*::HttpResponse( 

in long cid, •■ 
■ in FileLoc where; •' • • * 

in sequence<octet> data) 
cid: the identifier of. the connection between the 
HTTP client and the DCM. 

where- informs the client that this message is the 
first the last or a middle one of the response 

webData: contains a part or the entire response 
according to the HTTP protocol used through the con- 
nection identified by the cid parameter. - 
r00481 This is the prototype of the function to be im- 
plemented in the client which allows the DCM (acting as 
a HTTP server) to give back to the client a iHTTF 're- 
sponse corresponding to a previously receded HTTP 
request from that client through that connection . dent,- 

fied 'by "cid". ' '•' ' 
T00491 The error codes are the followmgs. 

WebProxy -ESIZE: the data exceeds the size of 
the buffer in the receiver. The receiver not received 
or processed the data. It is left to the implementation 
how the sender reacts to this status: _ . 

WebProxy::EFAILED: the receiver has aborted 
the transfer of the current sequence of data transfers, 
the sender shall abort the transfer of the current se- 
quence. 

WebPr6xy::ECID: The cid is unknown. 
robSO] In HAVi, the designer of a target device can de- 
cide which user control protocol (HAVi currently spec, 
fi es twdp>otoc0.s)to.mplemeh^ 
to provide some user control capabilities as specified in 
HAVi. For the controller application, it is nec essary xo 
know whether a particular target is user^control capable 
or not This is the goal of an attribute in the HAVi registry. 
The Registry is a database where all software elements 
are registered (including DCM and application moduley 
Any software element can query the database. Each 
time an element is added or removed,* corresponding 
network event is generated. An element is registered 
wth a set of attributes to characterize rt. One of these 
attribute is the GUIREQ attribute. The possible values 
are: ' ' "" " ' . ' . .... , . ... . . t , •; - ; .. 



mand towards the DCM of the selected target according 
to that protocobTo send the HTTP command, the client 
appS fen first establishes an HTTP connection^ 
me target DCM (callingthe DCM::HttpOpen method) 
s and then performs one or several calls .(depending on 

DCM in term of the HAVi message size) to the DCM. 
The DCM then uses DCM: Http Request to send itsJT- 
TP request. Once the target receives the c°rnmand.rt 

10 sends'back the Home HTML page «^ *J 
devicetotheclientbycallingoneormoretimestheclerrt 

method called "HttpResponse". The client application 
"he browser) then interprets the HTML script and dis- 
nlavs the Use p Interface. ' 4 '" ' v . ■ ! 

rs ioOS3] Thebridgefunctionisimplementedinadevice 

called thebridge device or simply ^bridge) wh,ch..s 
connected to both sub-networks as shown in Figure 3 
(device C). Thus it has to contain, at least, the pro toco 
Sassho W intheFigure4,SincetheSSDPprotoco. 

20 requires some multicast capabilities, the. IP layer ^ 
IGMP ('Internet Group Management Protocol ) compli- 

flint " ' ■ 

[0054] The moderation of a UPnP device .or sery.ee 
seen f rom the HAVi sub-network will now be described 
2S [0055] , The UPnP network is composed offices 
hat offer-access to some network.serv.ces 
protocolvshould permit the discovery of the services 
available in the network and indirectly the dev.ee that 
hosts the service. The HAVi network is composed ° 
so vices that contain one or more functional components 
Equivalent to services in UPnP). To represent a dev.ee 
we have to use the DCM representation. To represent 
functional component we have to use the FCM repre- 
sentation. In HAVi, the User interface protocol .s man- 
- 35 aged through the DCM API 
[0056] Consequently : 



. NOjMEED • ■ 4S 

. " DDI (the basic Ul protocol in HAVi) 

. HAVLET (the Java based Ul protocol in HAVi) 

[0051] The invention proposes to add a new value for 
this attribute as the following. sQ 

. HTTP (the HTTP/HTML paradigm in HAVi) 

roOS21 When a user wants to control a device, its as- 
sociated client application, typically an HTML browser, 
exposes the set of network devices HTTP/HTML capa- » 
ble (by querying the Registry on the corresponding 
GUIREQ attribute value). The user selects one of these 
and the client application can send the HTTP GET com- 



A UPnP device will be represented by a DCM in the 
bridge device. 

This DCM will contain the HTTP extra API. 
. A UPnP service (except for the HTTP service) will 
be represented by a FCM in the bridge device. 

[0057] It is mandatory to register these DCMs and FC- 
Ms through the HAVi REGISTRY service to allow any 
other HAV. object to discover them and, thus, to be able 
Toperate them. The registration consists in reg.ster.ng 
the HAV. addresses of these software elements and the 
mandatory attributes according to the HAVi spec.f.ca- 
tion: 

. Type of software element (either DCM or GENERIC 

- HLHD (unique hardware identifier: computed by the 
bridge device) 

Device class (LAV - meaning Legacy device) 

GUI Req (HTTP) , 
DeviceManuf acturer (manufacturer of the UPnP de- 
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vice/service) < 
SoftwareElement Version (computed by the bridge 
device) * ■ 1 f ;• 
UserPreferredName (computed by the bridge de- 
vice - based on the-UPnP ^service/device name) 

[0058] Before the bridge device is able to activate and 
register a DCM/FCM corresponding to a UPnP device/ 
service, it has to detect its presence within the UPnP 
sub-network. 

[0059] According to the SSDP (Simple Service Dis- 
covery Protocol) of UPnP, the bridge device acts as a 
SSDP client and server. Once the bridge device is con- 
nected to the home network, its SSDP client has to que- 
ry theUPnP sub-network by sending the multicast OP- 
TIONS message over UDP/IP to query the SSDP serv- 
ers. The SSDP OPTIONS message will have the follow- 
ing format according to the HTTP specification: • 

OPTIONS _*_ HTTP/1. .1 Request-ID: uuid: 
1 31 3AII- Locations: <httpu ://bridge. com/bar: 11 1T> 
[0060] This message .contains the type of services 
concerned by the query (_*_ meaning : all), the version 
number of HTTP, a unique identifier to match ;the r , re- 
sponse with the query (the value shall respect a format 
described irvthe RFC 2518), and the URL the responder 
will use to give; back its response(s) (the port number 
1111 correspond to the SSDP client of the bridge). *- , 
[0061] All UPnP devices will send back one or several 
SDDP OPTIONS responses (one by service implement- 
ed within the device) containing the name of the service, 
the network location of the service (the URL, used to 
reach the service), the protocol to be used to communi- 
cate with the service and a set of data to describe the 
device which hosts the service according to the follow- 
ing: 

Device manufacturer name 
Device name 

A URL to obtain an icon representing the device 

[0062] -The bridge device parses all responses and: 

For each new device detected, it installs and de- 
clares a HAVi DCM and registers it with its well 
. specified attributes as described earlier. . 
For each new service type : for which the bridge 
wants to offer the access to the HAVi network, it in- 
stalls and declares a HAVi FCM and registers it with 
its well specified attributes as described earlier. 

[0063] Consequently the DCM, respectively the FCM 
shall maintain a set of configuration data to be able to 
identify and join its associated UPnP device, respective- 
ly service. 

[0064] For the DCM: 

The URL to join the HTTP server of the UPnP device 
(if this service is implemented in the device) 
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The Device manufacturer name . 
The Device name 

The URL to get an icon representing the device 

5 [0065] , For the FCM:.v . «. 3 i\ ■■; 

- The URL to join the UPnP t seryice.. 

The type of the UPnP service, (printer for.example) 
The Device manufacturer name of the UPnP host 
io device . • - : . 

The service-^ name . of the UPnP service 

(PrinterRoom2 for example) - 

The URL to get an icon representing the device 

is [0066] When a UPnP device is plugged into the net- 
work, it has to send the SSDP ANNOUNCE message 
containing the name of the network service it provides , 
the network location and protocol to be used to commu- 
nicate with it; The SSDP server of the bridge is listening 

20 to the well known multicast port number. Thus for each 
incoming ANNOUNCE message, the bridge device will 
parse the message according to the manner described 
below.. 

[0067] For each detected UPnP device/service, the 
25 bridge device installs a DCM/FCM to control this UPnP 
device/service as explained in the previous sections. 
The HAVi sub-network has the knowledge of these new 
elements. Any application in the HAVi sub-network, can 
then control a UPnP target. In our example (cf. Figure 3) 

30 > the A device provides the user with the list of, devices in 
its home network represented by icons. To. realize that, 
the user application , of A (an HTML browser) has previ : 
ously queried the HAVi registry to get all .the. identifiers 
of DCMs which were able to offeran HTTP API. 

35 [0068] The user would like to control the E device us- 
ing HTML and selects its associated icon. The user ap- 
plication in A establishes .the HTTP connection with the 
associated DCM. The User application then sends the 
HTTP request to the DCM calling the function DCM::Ht- 

40 tpRequest. The DCM then establishes the TCP connec- 
tion according to.HTTR between ,the bridge device (C) 
and the UPnP target (E) and forwards the HTTP re- 
quest. To establish the connection, the DCM will use the 
URL associated with the HTTP server service of the UP- 

45 nP target previously registered as configuration data. 
[0069] Once the HTTP command (the HTTP_GET 
command for instance) is received by the UPnP target, 
it sends back the response (an HTML page) to the DCM 
which will forward this response to the source of the re- 

so quest. 

[0070] The modelization of a HAVi target seen from 
the UPnP sub-network will now be described. 
[0071] The UPnP model is based on the TCP/UDP/IP 
protocols. Consequently, a UPnP device is a network 
55 entity which can be reached through its I P (Internet Pro- 
tocol) address. A service is an entity within the applica- 
tion layer (over TCP or UDP) which can be reached 
through a port number. The port number identifies the 
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connect p* ^ 

we basically have two solutions: 

ThP first solution is based on port numbers and is 
" ::ed;o^helto1thedescri P tion,asexp.a,nedbe- 

Te second solution is based on multiple IP ad- 

component (.». a DCM o. an FCM 

UPnP network. 



the .ocation where the service ^e. Con , 
there is no need to represent a HAV. oeyic 

w AVi functiona component vr / 

Siri— <— TCP - UDP) * 

rnn7dl consequently, once the bridge aexecis 
[0074] ^° n = e ^ ' FCM) for which a proxy UPnP 
target (erther a DCM or a h SSDP mu | tj . 

service can be * tes the R 

cast ANNOUNCE message to the urnr » 
The Sowing ANNOUNCE «~«£^aWP 
nounce a HTTP server service represented by a Hi 
proxy within the bridge device: 
P ANNOUNCE server H TTP 
n L0 cation:httpu.//bridge.com:l23 
«„« Thl i irl -server HTTP" is the type ot the serv 
TrLTSS ^fie« contains the URL to reach the 

(either UDP or TCP). ANNOUNCE message 

device hosting the service. 



. Device manufacturer name - 

to the description presented ea ' l,er p . g „ majntain 
[0079] Consequently^ 
w a set ol conf.gurat.on date to » De a FCM) .. T his 

iSi.i, '' The us .< would like to control the device B us- 

device B-embedded I , .the bndge ^ ^ ^ 

pr oxy then .-«^ H ^Sti hB ft.DCM,l* 

30 DCM representing the H avi ^ The User applica- 

The DCM then send back the ^ HTTP 
HTML home page fo .nstence i y ^ ^ 

r.rr>w (method <client>..Httpnespon&e, » 
proxy imwiiw su b-network. The Hi ir 

" » <*" 

45 network types and may aiso o« hh 

of networks. 



so 
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Claims 

Method for bridging a HAVi » UP " 

nP sub-network compns.ng the steps ot. 

. discovering UPnP devices and/or services on 
the UPnP sub-network and corresponding to a 

o, each discovered UPnP device as a HAV. 
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DCM and of each discovered .UPnP service as ■ 
a HAVi FCM on the HAVi sub-network. 

2. Method according to claim 1 , wherein the discovery 
step is carried out using Simple Service Discovery s 
Protocol (SSDP) functions. ,* *. 

3. Method for bridging a HAVi sub-network and a UP- 
nP sub-network comprising the steps of: 

- ' discovering HAVi software elements of the 
HAVi sub-network corresponding to a selection 
criterion; : : .r ..■ ; V . . . , 

- representing, in a sub-network bridging device, 
^ each of said discovered elements by ;a:UPnP fs 
proxy service identified by a port number attrib- ■ 
. uted by said sub-network bridging device; and 
- ; announcing each said proxy services on the 
UPnP sub-network. . ■ . * . - 

' m .i - i 20 

4. Method according to claim 3, wherein the discovery ; 
step comprises the step of requesting, by said sub- 
network bridging device, a list of software elements 

^ from a HAVi registry. - i ■* 1 ; : \ 

5. . Method according, to one of the precedingdaims;, 

whereinthe selection. criterion, is HTTP/HTML ca- * : < ^ 

pability . c. .■ - 3 . u* j v •■■ ':\v 

6. Device for bridging a UPnP subnetwork and a HAVI 30 
sub-network implementing the methods according 

to one of the claims 1 to 5. , 
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